Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000081_owner-urn-ietf _Wed Nov 6 20:52:27 1996.msg

Internet Message Format | 1997-02-19 | 4KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA21135 for urn-ietf-out; Wed, 6 Nov 1996 20:52:27 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA21130 for <[e-mail]>; Wed, 6 Nov 1996 20:52:25 -0500
Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA16212  (mail destined for [e-mail]); Wed, 6 Nov 96 20:52:23 -0500
Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa26936;
          6 Nov 96 20:52 EST
Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM)
    id AA06320; Wed, 6 Nov 1996 20:52:18 -0500
Date: Wed, 6 Nov 1996 20:52:18 -0500
Message-Id: <[e-mail]>
From: Lewis Girod <[e-mail]>
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> (message from
    Terry Allen on Wed, 6 Nov 1996 16:35:41 -0800 (PST))
Subject: Re: [URN] Re meaningful names
Sender: [e-mail]
Precedence: bulk
Reply-To: Lewis Girod <[e-mail]>
Errors-To: [e-mail]

   Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST)
   From: Terry Allen <[e-mail]>

   Well, no.  The name is the name; if you come to dislike it or think
   it doesn't mean the right thing you can map something else onto it
   in a new name space.  If an existing name space uses "Mainframes",
   so be it; it will still work just fine as part of an unambiguous
   identifier (even if users have to be told "what name space FOO
   calls Mainframes we now call Enterprise Systems").

Right, that was what I meant by ``overall cruftiness''.  At any given
time large portions of the namespace are providing backwards
compatibility for out-of-date semantics.

   | Of course, as you point out there is no way to stop people from
   | putting semantics into names; the most effective way to deal with the
   | issue is to implement a system of user friendly names over the top of
   | URNs; 99% of the time the user would see and type only a UFN, and
   | these UFNs would be resolved to the URNs that could then be used as
   | long-lived references.

   Twice the work or more, doesn't deal with grandfathering, prone
   to error; the most effective way to deal with the issue is to
   drop your objection to meaningful names.

It is more work (though how much more is hard to say), but it might
prove really useful.  I don't think it would impact grandfathering at
all; grandfathered names could have a UFN alias or they might just be
typed in as URNs.  Prone to error?  UFNs wouldn't have the longevity
characteristics that URNs hopefully would have, if that's what you
mean -- that's why you don't use them in published links.

   Lewis:
   | One idea we were experimenting with here was to use a subset of ASCII
   | that included only numerals, punctuation and consonants, which would
   | make most words hard to express (at least in some languages).

   I cannot imagine that such an approach would find favor in the real
   world.

Outside of the context of a UFN infrastructure, no; but the real world
has found utility in many namespaces as unfriendly as that... as long
as people don't have to get too involved with them.  As for whether
such a scheme would ever gain real world acceptance, that probably
depends largely on the implementation of a UFN scheme, and whether the
real world finds it to be sufficient for their purposes.

This discussion of UFNs is probably getting off the topic -- the part
of this opinion that is relevant to the topic is that in the backs of
our minds we should remember that semantics in names and longevity
seem to be at cross purposes, and it would be nice if at some time in
the future most new names were free of semantics.  Given that, should
we build in additional mechanisms specifically to support semantics in
URNs?


    -lewis